Are "we" sure it's a size issue, rather than an int vs float issue?

in our case, the similarly sized GhUKEzE2OTM1NDA5NDQ5NTk3MjA1OTI= does not cause the pre-change panic that GiAKHjE2OTM1NDA5NDAzNzMwNDU3MjcuMDAwMDAwMDAwMQ== does.

Yeah, its a capacity failure on trying to create a slice to track the revisions. The panic occurs on a uint64, so it cannot be a float issue

Yeah, its a capacity failure on trying to create a slice to track the revisions. The panic occurs on a uint64, so it cannot be a float issue

The failing token GiAKHjE2OTM1NDA5NDAzNzMwNDU3MjcuMDAwMDAwMDAwMQ== decodes to \x1a \n\x1e1693540940373045727.0000000001

So if it's a size issue, we'd expect \x1a \n\x1e1693540940373045728 (GiAKHjE2OTM1NDA5NDAzNzMwNDU3Mjg=) to throw as well?

So if it's a size issue, we'd expect \x1a \n\x1e1693540940373045728 (GiAKHjE2OTM1NDA5NDAzNzMwNDU3Mjg=) to throw as well?

We would, except the lack of a decimal point means that it is interpreted as size 0. This is because legacy Postgres revisions were stored as a decimal representing a range, where X.Y was a range from X->Y.

In the case of the first revision given, 1693540940373045727.0000000001 became 1693540940373045727 -> 1 for a size of 1693540940373045726. In your second example, 1693540940373045728 became 1693540940373045728->1693540940373045728, with a size of 0.

This is all because legacy Postgres revisions were stored in this particular format, and giving a CRDB revision that "just so happened" to hit the legacy parsing code perfectly

Ah, interesting on the postgres history, ty.

so here the second part of the decimal timestamp is correctly being parsed as an xmin candidate, and correctly assigned to xmin on L208, as if it was a postgres revision.

it's correct then to return the error after calculating the range, not dismiss the float timestamp sooner.

thanks again!